Transport mechanisms for dynamic rich media scenes

ABSTRACT

A transport mechanism for supporting the download of SVG over FLUTE or UDP. A RTP payload format is specified that enables live streaming and the streaming of rich media content. According to the present invention, rich media content is encapsulated in RTP packets based upon the payload format at the sender. With the present invention, an efficient framework is provided for satisfying several use cases or scenarios that involve rich media transmission.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.11/474,816, entitled “TRANSPORT MECHANISMS FOR DYNAMIC RICH MEDIASCENES” filed Jun. 26, 2006, which claims priority to U.S. ProvisionalPatent Application Ser. No. 60/694,440 entitled “TRANSPORT MECHANISMSFOR DYNAMIC RICH MEDIA SCENES” filed Jun. 27, 2005. Each of theseapplications is incorporated herein in its entirety as if set forth infull.

FIELD OF THE INVENTION

This present invention relates to transport mechanisms for streaming anddownloading rich media content. More particularly, the present inventionrelates to transport mechanisms for streaming and downloading rich mediacontent containing Scalable Vector Graphics (SVG) over point-to-pointand broadcast/multicast services.

BACKGROUND OF THE INVENTION

SVG is a useful format for media presentations. SVG can provide a layoutwithin which other media can be embedded and played, for real-time stockand traffic information, and for entertainment purposes. In recentyears, Mobile Scalable Vector Graphics (Mobile SVG), has been adopted asthe new imaging standard by the Third Generation Partnership Project(3GPP) for playing a pivotal role in bringing improved graphics andimages to mobile devices.

Recently, 3GPP and the Open Mobile Alliance (OMA) have begun work on thestreaming of rich media over Portable and Simple Syndication (PSS) andMultimedia Broadcast/Multicast Service (MBMS). This requires the abilityto combine both raster and vector graphics with existing audio, video,and timed text media. However, unlike existing frame-based media, SVGfollows for declarative animation with a specified presentation starttime and duration. All the different tracks in the rich media need to betemporally synchronized and streamed via real-time transport protocol(RTP) packets using the track information contained within the ISO BaseMedia File Format. Currently, the RTP payload specifications cater tothe packetization of frame-based media and results in synchronizationproblems among frame-based and non-frame based SVG.

Currently, SVG and other media can only be downloaded and progressivelydownloaded via HTTP. There is currently no mechanism for permitting thedownload of SVG over FLUTE, which is a Cascading Style Sheets, Level 2(CSS2) parser written in Java that implements SAC. SAC is an event-basedapplication program interface (API) for CSS parsers.

Additionally, due to the lack of an appropriate RTP payload format,there is currently no available mechanism for streaming SVG contentseither out of ISO base media files or directly from live content.

Previously, there has been work on transport mechanisms for mediaformats such as audio, video and timed text. Macromedia Flash, aproprietary format for vector graphics, does not have support for realtime (RTSP/RTP) streaming Instead, Flash only uses progressivedownloading from a web server or http streaming via the FlashCommunication Server which only runs in a Windows environment.

SUMMARY OF THE INVENTION

The present invention provides for a transport mechanism for supportingthe download of SVG over FLUTE or the User Datagram Protocol (UDP). Thepresent invention also provides a specification of an RTP payload formatthat enables live streaming and the streaming of rich media content. Asused herein, “live streaming” refers to media streams from a liveencoder. According to the present invention, rich media content isencapsulated in RTP packets based upon the payload format at the sender.

The present invention provides for an efficient framework for satisfyingseveral use cases or scenarios that involve rich media transmission.

These and other objects, advantages and features of the invention,together with the organization and manner of operation thereof, willbecome apparent from the following detailed description when taken inconjunction with the accompanying drawings, wherein like elements havelike numerals throughout the several drawings described below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a depiction of an SVG transport mechanism in accordance withthe present invention;

FIG. 2 is a depiction of the format of the RTP payload fields in thetransport mechanism of the present invention;

FIG. 3 is a depiction of the RTP payload header for TYPE1 packets;

FIG. 4 is a depiction of the RTP payload header for TYPE2 packets;

FIG. 5 is a depiction of the RTP payload header for TYPE3 packets;.

FIG. 6 is a depiction of the RTP payload header for TYPE4 packets;

FIG. 7 is a depiction of the RTP payload header for TYPE5 packets;

FIG. 8 is a perspective view of a mobile telephone that can be used inthe implementation of the present invention; and

FIG. 9 is a schematic representation of the telephone circuitry of themobile telephone of FIG. 8.

DETAILED DESCRIPTION OF THE INVENTION

SVGT version 1.2 supports prefetching for progressive downloading.However, for real-time streaming, a scene may change through animationsand changes in scene states. This sequence of scene description and itsspatial/temporal modifications needs to be streamed from the server tothe players on the client device.

Logical scenes in SVG animations are grouped together using the <g>element. The SVGT 1.2 specification suggests that, for the case ofprogressive downloading and streaming, all scene definitions must bechildren of the root <svg> element in the DOM tree. Each adjacent toplevel <g> element should contain adjacent chronological scenes in theanimation.

Scene updates are incremental updates to the SVG DOM that get sent tothe client device one at a time. These updates include SVG elementaddition, element deletion, element replacement and element attributeupdate.

SVG supports media elements similar to Synchronized MultimediaIntegration Language (SMIL) media elements. Dynamic or real time mediaelements define their own timelines within their time container. All SVGmedia elements support the SVG timing attributes and run timesynchronization. The real time media elements are audio and video, andare embedded as follows in SVG:

-   <audio xlink:href=“1.ogg” volume=“0.7” type=“audio/vorbis”    begin=“mybutton.click” repeatCount=“3”/>-   <video xlink:href=“ski.avi” volume=“0.8” type=“video/x-msvideo”    x=“10” y=“170”/>

Furthermore, SVG can also embed other SVG documents, which in turn canembed yet more SVG documents through nesting. The embedded mediaelements can be linked through internal or external URLs in the SVGcontent.

The animation element specifies an external embedded SVG document or anSVG document fragment providing synchronized animated vector graphics.Like the video element, the animation element is a graphical object withsize determined by its x, y, width and height attributes. For example:

-   <animation begin=“1” dur=“3” repeatCount=“1.5” fill=“freeze” x=“100”    y=“100” xlink:href=“mylcon. svg”/>

On the other hand, static media such as images are embedded in SVG usingthe ‘image’ element, such as:

-   <image x=“200” y=“200” width=“100px” height=“100px”    xlink:href=“myimage.png”>

An overview of the transport mechanism of the present invention isdepicted in FIG. 1. As shown in FIG. 1, SVG is transported from a server100 to a client device 110 by dividing the content into three separategroups. SVG and other embedded SVG files, which are represented at 120,are transported in RTP packets 130, and an RTP session 140 transportsthe information to the client device 110. Embedded dynamic media 150 usemultiple RTP connections 160. An RTP session 140 is also used totransport the embedded dynamic media 150 to the client device 110.Embedded static media, represented at step 170, are downloaded by theclient device 110 via FLUTE at 180.

A first implementation of the present invention involves using the RTPpayload format to enable rich media streaming In this implementation,the RTP units are classified as follows. A TYPE1 packet contains one ormore than one sample description. A TYPE2 packet contains a complete SVGscene sample or one of its fragments. A TYPE3 packet contains a completeSVG scene update sample or one of its fragments. A TYPE4 packet containsa list of SVG elements that are currently active. A TYPE5 packetcontains sample dissimilarity information.

The duration of an SVG scene is specified within the SVG format itself.The format of an RTP packet containing SVG is shown in FIG. 2. Themarket bit M (1 bit) indicates whether the current packet contains thefinal fragment, if any, of an SVG sample. For TYPE1 packets, assumingthe rule that the sample description cannot be fragmented, the M bit isalways set to 1. For TYPE2, TYPE3, TYPE4 and TYPE5 packets, the M bit isset to 1 if it is either a complete sample or the final fragment of thesample. Otherwise, the M bit is set to 0. Whenever the client device 110receives an RTP packet 130 with the M bit set to 1, it regards thetransmission for the current sample as completed and starts to do thenext step (FEC checking and decoding).

The timestamp indicates the sampling instant of the SVG sample. ForTYPE1 packets, the timestamp is set equal to the timestamp of thefollowing packet. The client device 110 should ignore the timestamp forthis case. It should be noted that a setting of zero would break anylogic that the RTP client may have based on inter-arrival jittercalculation. A typical way to assign a timestamp for packets that do nothave an inherent time property is to associate the packet to thepreceding or succeeding packet and copy its timestamp. For TYPE2 andTYPE3 packets, the timestamp indicates the sampling instant of thecurrent SVG sample. For TYPE4 packets, since the list is sent once for aparticular group of scenes and scene updates, the timestamp for TYPE4 iswithin the start (the timestamp of first sample in the group) and theend (the timestamp of last sample in the group) times of the group. ForTYPE5 packets, since the sample dissimilarity information shows thedifference between the current and previous scene graphs, the timestampof the TYPE5 packet must be the same as the current sample.

For live streaming, an appropriate timestamp clock rate is used. Thisvalue should provide enough timing resolution for synchronizing SVG withother media. Unlike other media such as audio and video, there is nodefault sample size or sampling rate defined for SVG. The encodingapplication must take into account the delay constraints of thereal-time session and assess whether FEC, retransmission or othersimilar techniques are reasonable options for stream repair.

The usage of the remaining RTP header fields follows the rules of RFC3550, which can be found at www.faqs.org/rfcs/rfc3550.html, and theprofile in use. It should be noted that multiple fragments belonging tothe same sample are identified by both the ‘timestamp’ and ‘TYPE.’

The payload headers comprise a set of common fields followed by specificfields for each header type and sample contents. The fields common toall payload headers have the following format. The “Type Field” (3 bits)specifies which specific header fields follow. The following TYPE valuesare defined:

The RTP units are classified as follows. A TYPE1 packet contains one ormore than one sample description. A TYPE2 packet contains a complete SVGscene sample or one of its fragments. A TYPE3 packet contains a completeSVG scene update sample or one of its fragments. A TYPE4 packet containsa list of SVG elements that are currently active. A TYPE5 packetcontains sample dissimilarity information.

The “Reserved Bits Field” (R—4 bits) is used for future extensions. Thisfield must be set to zero (0×0) and is ignored by receivers.

The “Priority Field” (PR—2 bits) indicates the level of importance for aparticular sample. A higher value indicates a higher priority. Forexample, in circumstances where data is transmitted through a mediagateway, more important packets are sent through a reliable channel,while less important packets are sent through a less reliable channel orare simply discarded. Additionally, such a priority mechanism allows theencoder to apply partial FEC protection. Furthermore, with such apriority system, the sender can duplicate the more important packets incase of packet loss. This flag is present in all five of the packettypes.

The “Counters Field ” (CTR—7 bits) is tied with the PR flag. Each of thefour individual counters is incremented by one for each new packet ofthe corresponding priority. The CTR field is warped to zero afterreaching the maximum limit. A discontinuation in the sequence numberindicates a lost packet. A discontinuation in the counter value (of acertain priority) indicates the priority of a lost packet. Thisphenomenon is depicted in Table 1 below.

TABLE 1 Seq. No. 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 TYPE 1 1 44 3 3 3 4 4 5 3 3 3 1 2 PR 3 2 3 3 2 2 0 1 1 2 2 1 2 1 3 CTR3 1 2 3 4CTR2 1 2 3 4 5 6 CTR1 1 2 3 4 CTR0 1 CTR 1 1 2 3 2 3 1 1 2 4 5 3 6 4 3

The following sections specify the different payload headers for theTYPE values. TYPE1 headers, depicted in FIG. 3, are used to transportsample descriptions (both static and dynamic). The RTP transmissionalways starts with one or more than one TYPE1 packet containing staticsample descriptions, including the one for the first TYPE2 packet. TheTYPE R, PR and CTR fields are used as above, followed by the sampledescriptions. Each sample description contains the following four fieldsin order: SDID|content encoding|text encoding|content script type.

The “Sample Description Index Field” (SDID—8 bits) is an index used toidentify the sample descriptions (SD) to help decode the payload. Thereare two types of SDID: static and dynamic. The static and dynamic SDsuse them respectively. The static sample description remains activeduring the whole presentation, while the dynamic sample descriptionremains active until the next scene sample is presented. The static anddynamic sample descriptions can be distinguished by their associatedSDID values. Both the static and dynamic sample description cannot bemodified during their active periods. Both sample descriptions aretransmitted in TYPE1 packets. The static SDID is used to identify staticsample descriptions. The dynamic SDID is used to identify dynamic SDs.Larger values are assigned to the dynamic SDID, while lower values areassigned to the static SDID. For example, 0-63 are assigned to staticSDIDs; 64-255 are assigned to dynamic SDIDs. This assignment thresholdis transmitted out-of-band in the Session Description Protocol (SDP)before RTP transmission. By default, the first 64 SDIDs are assigned tobeing static, while the rest is assigned to be dynamic. However, thisassignment can vary depending on the server, network conditions, numberof sample descriptions, length of sample descriptions, etc.

The SDID's are connective integers, as discussed in the followingexample. The allowed value range of static SDIDs is from 0 to 63. Inother words, the maximum number of allowed static Sample Descriptions is64. It is not necessary for them to start from 0, but they must beconnective. The allowed value range of dynamic SDIDs is from 64 to 255.During each active period, the maximum number of allowed dynamic sampledescriptions is 192. It is not necessary for them to start from 64, butthey must be connective.

The length of the version-profile, text-encoding-type andcompression-type are 16, 8 and 8 bits, respectively. The “contentencoding” field is a null terminated string with possible values being‘none’, ‘bin_xml’, ‘gzip’, ‘compress’ and ‘deflate’. This is specifiedaccording to www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#3.5. The‘text encoding’ field is a null terminated string with possible valuesselected from the ‘name’ or ‘alias’ fields (depending upon theapplication) in the IANA specifications (which can be found atwww.iana.org/assignments/character-sets) such as US-ASCII, BS 4730, etc.

The “content script type” (CSCR) field identifies the default scriptinglanguage for the given sample. This attribute sets the default scriptinglanguage for all of the instances of script in the document. The valuecontent type specifies a media type. If scripting is not enabled, thenthe value for this field is 0. The default value is “ecmascript” with avalue of 1.

A TYPE2 header, depicted in FIG. 4, is used to transport complete SVGscene samples. This unit is used in the case when the SVG sample issmall enough to be transported in one unit without having to makesmaller scene fragments. The TYPE, PD, SDID and R fields have similarinterpretation as in TYPE1.

The “Number of Padding Bits Field” (PAD—3 bits) indicates how manypadding bits are in the final octet of the real payload.

The GRP field (4 bits) indicates to which group the scene belongs.Generally, one scene followed by one or more scene updates constitutes agroup. However, the grouping nature is flexible and can be determined atthe authoring level. Grouping allows a current list of active elements(TYPE4) to be sent once per group, and allows for more efficient errorcorrection mechanisms.

The Sample Description Index Field (SDID) contains a reference to thesample description that must be used to parse the scene descriptioncontained in the particular payload.

The LNK flag (L—1 bit) indicates whether the current SVG sample containsan audio, video, animation or image tag, indicating that the SVGreferences external audio, video, SVG or image content. This field canhelp the client device 110 decide the decoding order and prepare for newtransmissions of external media content.

The SIM field (3 bits) is used to denote if Sample DissimilarityInformation (SDI) is present or not. SDI provides information as to howa sample is different from the scene graph currently on the client. Thisinformation can either compare two scenes or two scene graphs (i.e.,scenes with scene updates). The choice depends upon the nature of theserver as well as how the client can handle such information.

The SIM field has several values. SIM=000 if the current packet does notcontain any SDI. SIM=001 if the next sample and the sample in thecurrent packet are identical. SIM=010 if the next sample is an empty SVGsample. SIM=011 if the two samples are different, and the SDI isappended at the end of current packet. This occurs when the length ofthe SDI is small enough to be appended. TYPES2-5 support appending theSDI. SIM=100 if the two samples are different, and the SDI is sent inTYPE 7 or TYPE 9 packets when the length of the SDI is long.

The S flag (1 bit) indicates whether the current packet contains thestarting point of the current sample. While the M flag indicates theending point of a current sample, the S flag indicates the startingpoint. The combination of the M and S flags provide the followinginformation. When M=1 and S=1, the current packet contains a completesample. When M=0 and S=1, the current packet contains the first fragmentof a sample. When M=1 and S=0, the current packet contains a finalfragment of the sample. When M=0 and S=0, the current packet contains amiddle fragment of a sample. In these situations, “sample” refers to anSVG scene, scene update, SDI or an active list of SVG elements.

A TYPE3 header is used to transport whole SVG scene update samples. Thisunit is used in the case when the SVG scene update is small enough to betransported in one unit without having to fragment into smaller samples.All of the fields have similar interpretations as in TYPE2 headers. Ascene update contains information for adding, deleting, and replacingelements and their attributes in the current scene.

The TYPE4 header contains definitions of currently active SVG elementsin the scene graph at that particular time stamp. This allows the clientto better manage elements and memory. All of the fields have similarinterpretations as the other types. The GRP field allows TYPE4 packetsto be transmitted only once per group for optimization. When to transmitTYPE4 packets in the group (whether at the beginning, middle or end) isdetermined by the server 100 or by any special instructions accompanyingthe SVG content. The interpretation of the fields is the same as in theother TYPE headers. An SVG definitions block containing currently activeSVG elements is present in this TYPE. This allows the client to checkits SVG scene graph to make sure that it contains all the SVG elementsthat are currently active. With the introduction of this TYPE4 format,errors in the scene graph due to packet loss may be corrected. In theSVG specification, a <defs> . . . </defs> block contains the SVG elementlist.

The TYPE5 header contains the SDI, in the event that it is too long tobe appended to TYPES2 and 3 headers. The interpretation of all thefields is the same as in the other TYPE headers.

A second implementation of the present invention involves thetransmission of dynamically embedded media. In this implementation, SDPinformation is provided only for internally embedded dynamic media,while the receiver can request externally embedded dynamic media fromthe external streaming server. One clock rate must be specified in theSDP for the whole SVG presentation. The resolution of the clock must besufficient for the desired synchronization accuracy and for measuringpacket arrival jitter. The clock rate of the embedded dynamic mediafiles within the presentation needs to be considered. For example, ifthe presentation contains embedded video, the suggested clock will be noless than 90,000.

Multiple RTP connections within one session are used to transmit thedynamic embedded media. It is the responsibility of the encoder tocalculate the time stamp when generating the RTP packets in order toensure proper synchronization. The start-time of each sample needs to bemapped to the time stamp of the RTP packets.

Only the source locations of internally embedded dynamic media areindicated in SDP. The embedded media may come from a track in the mainfile, an internally embedded file in the same directory, or an item froma 3GPP file in the same directory. There are four ways to indicate theselocations:

-   1. file_name=“video2.h263”-   2. box=-moov;track_ID=1-   3. item_ID=3-   4. item_name=“video4.h263”

In this situation, the ‘item_ID’ and ‘item_name’ are the associatedinformation for the embedded item, which is saved in ItemLocationBox andItemInfoBox, respectively, in a 3GPP file.

The SDP session specifies the SVG format, its clock rate and the SDIDthreshold. An example of a media-level description in SDP is shownbelow. In this case, four H.263 vedio media with the same format areembedded in the presentation. Each (“a=fmtp”, “a=-rtpmap”) pairdescribes one source location.

-   m=svg+xml 12345 RTP/AVP 96-   a=rtpmap:96 X-SVG+XML/100000-   a=fmtp:96 sdid-threshold=63;version_profile=“1.2”;base_profile=“1”-   m=video 49234 RTP/AVP 98 99 100 101-   a=rtpmap:98 h263-2000/90000-   a=fmtp:98 box=moov;track_ID=“1”;profile=“3”;level=“10”-   a=rtpmap:99 h263-2000/90000-   a=fmtp:99 file_name=“video2.h263”;profile=“3”;level=“10”-   a=rtpmap:100 h263-2000/90000-   a=fmtp:100 item_ID=″3″;profile=“3”;level=“10”-   a=rtpmap:101 h263-2000/90000-   a=fmtp:101 item_name=“video4.h263”;profile=“3”;level=“10”

There is no need to specify the source location of the main SVG file.However, if there is an embedded SVG file or content in the main SVGfile, then the source location of the file or content should bespecified in SDP as an individual media-level SDP description.

A third implementation of the present invention involves thetransmission of static embedded media. The static embedded media files(e.g. images) can be transmitted by either (1) sending them to the UE inadvance via a FLUTE session; (2) sending the static media to each clienton a point-to-point bearer before the streaming session, in a mannersimilar to the way security keys are sent to clients prior to an MBMSsession; (3) having a parallel FLUTE transmission session independent ofthe RTP transmission session, if enough radio resources are available,or (4) having only one transmission session to transmit all of the datadue to the limited radio resources. Such a transmission has data fromtwo user sessions—one for RTP and the other for FLUTE.

Options (1) and (2) above can be implemented at the SVG group level(comprising a group of scenes and scene updates), rather than at thepresentation level. Therefore, immediately before the group istransmitted, the embedded static files can be sent in a separate FLUTEsession.

The SDP information is provided for only internally embedded staticmedia or SVG content. For a FLUTE session, the receiver may explicitlydownload the externally embedded static media or SVG content from theserver. The URLs of the internally embedded media are indicated in thefile delivery table (FDT) field inside of the FLUTE session, rather thanin SDP. The syntax of the SDP description for FLUTE has been defined inthe Internet-Draft: SDP Descriptors for FLUTE(www.ietf.org/internet-drafts/draft-mehta-rmt-flute-sdp-02.txt).

The following are other alternative implementations for the presentinvention.

Implementation 4: Same as implementation-1 but with the fieldsre-ordered.

Implementation 5: The first implementation discussed above specifies theminimum possible size for the fields in the payload header format.Certain fields can be longer than the specified values.

Implementation 6: In this implementation, PtM is 3GPP MBMS; PtM is 3GPP2BCMCS; PtM is DVB-H IPDC; and PtM is OMA BCAST.

Implementation 7: Scene dissimilarity information could providedifferences across scenes, scene updates and/or scene graphs, acombination of one or more scenes and scene updates.

Implementation 8: The frequency of transmission of a current active listof SVG elements could be either for a group of scenes and scene updates,for only each scene, or at a predetermined time interval. This choice isat the discretion of the server, authoring environment and/or availablebandwidth.

Implementation 9: The RTP payload format for rich media could be appliedto pre-authored/pre-recorded content, as well as to live content.

Implementation 10: The SDP information for the FLUTE session can haveflexible default values for parameters such as clock rate and the SDIDthreshold.

FIGS. 8 and 9 show one representative mobile telephone 12 for which thepresent invention may be implemented. This mobile telephone 12 can serveas a client terminal or a server depending upon the particular system atissue. It should be understood, however, that the present invention isnot intended to be limited to one particular type of mobile telephone 12or other electronic device. The mobile telephone 12 of FIGS. 8 and 9includes a housing 30, a display 32 in the form of a liquid crystaldisplay, a keypad 34, a microphone 36, an ear-piece 38, a battery 40, aninfrared port 42, an antenna 44, a smart card 46 in the form of a UICCaccording to one embodiment of the invention, a card reader 48, radiointerface circuitry 52, codec circuitry 54, a controller 56 and a memory58. Individual circuits and elements are all of a type well known in theart, for example in the Nokia range of mobile telephones.

The present invention is described in the general context of methodsteps, which may be implemented in one embodiment by a program productincluding computer-executable instructions, such as program code,executed by computers in networked environments.

Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of program code for executing steps of the methods disclosedherein. The particular sequence of such executable instructions orassociated data structures represent examples of corresponding acts forimplementing the functions described in such steps.

Software and web implementations of the present invention could beaccomplished with standard programming techniques, with rule basedlogic, and other logic to accomplish the various database searchingsteps, correlation steps, comparison steps and decision steps. It shouldalso be noted that the words “component” and “module” as used herein,and in the claims, is intended to encompass implementations using one ormore lines of software code, and/or hardware implementations, and/orequipment for receiving manual inputs.

The foregoing description of embodiments of the present invention havebeen presented for purposes of illustration and description. It is notintended to be exhaustive or to limit the present invention to theprecise form disclosed, and modifications and variations are possible inlight of the above teachings or may be acquired from practice of thepresent invention. The embodiments were chosen and described in order toexplain the principles of the present invention and its practicalapplication to enable one skilled in the art to utilize the presentinvention in various embodiments and with various modifications as aresuited to the particular use contemplated.

1. A method for delivering content to a client device, comprising:transmitting a signal to the client device, the signal carrying within apacket stream a multimedia presentation specified using a markuplanguage, wherein the multimedia presentation includes at least onescene description and at least one scene update, and wherein the packetstream includes scene packets, each of which contains informationderived from either one of the at least one scene description or one ofthe at least one scene update
 2. The method of claim 1, wherein eachscene packet includes priority information for the content containedwithin the scene packet.
 3. The method of claim 2, wherein each scenepacket includes sequence information relative to the priorityinformation for the scene packet.
 4. The method of claim 1, wherein themultimedia presentation includes SVG.
 5. The method of claim 1, whereinthe packet stream comprises a plurality of real time transfer protocolpackets.
 6. The method of claim 1, further comprising transmittingembedded static media outside of the packet stream.
 7. The method ofclaim 6, wherein the embedded static media is transmitted via FLUTE. 8.The method of claim 6, further comprising transmitting embedded dynamicmedia through a plurality of real time transport protocol connections.9. The method of claim 1, wherein each scene packet includes a typefield indicative of the content of the scene packet.
 10. A computerprogram product for delivering content to a client device, comprising:computer code for transmitting a signal to the client device, the signalcarrying in a packet stream a multimedia presentation specified using amarkup language, wherein the multimedia presentation includes at leastone scene description and at least one scene update, and wherein thepacket stream includes scene packets, each of which contains informationderived from either one of the at least one scene description or one ofthe at least one scene update.
 11. The computer program product of claim10, wherein each scene packet includes priority information for thecontent contained within the scene packet.
 12. The computer programproduct of claim 11, wherein each scene packet includes sequenceinformation relative to the priority information for the scene packet.13. The computer program product of claim 10, wherein the multimediapresentation includes SVG.
 14. The computer program product of claim 10,wherein the packet stream comprises a plurality of real time transferprotocol packets.
 15. The computer program product of claim 10, furthercomprising computer code for transmitting embedded static media outsideof the packet stream.
 16. The computer program product of claim 15,wherein the embedded static media is transmitted via FLUTE.
 17. Thecomputer program product of claim 15, further comprising computer codefor transmitting embedded dynamic media through a plurality of real timetransport protocol connections.
 18. The computer program product ofclaim 10, wherein each scene packet includes a type field indicative ofthe content of the scene packet.
 19. An electronic device, comprising: aprocessor; and a memory unit operatively connected to the processor andincluding computer code for transmitting a signal to a client device,the signal carrying in a packet stream a multimedia presentationspecified using a markup language, wherein the multimedia presentationincludes at least one scene description and at least one scene update,and wherein the packet stream includes scene packets, each of whichcontains information derived from either one of the at least one scenedescription or one of the at least one scene update,
 20. The electronicdevice of claim 19, wherein each scene packet includes priorityinformation for the content contained within the scene packet.